One of the characteristic features of many existing database systems that serve a large number of users, such as those used in telecommunications systems, is the need to store a substantial amount of data items of various different types for each of a huge number of users (e.g. subscribers) of these systems. For example, the data may include location data associated with a mobile system subscriber, which is required to determine routing information for setting up a call session to the subscriber's registered terminal. Alternatively, the data may be service-controlling data associated with the subscriber, which may be used to determine whether a terminating call should be diverted to a further destination and/or whether an originating call can be permitted, depending on the location. The identifiers of one or more terminals that are used by a subscriber may also need to be stored.
In the telecommunications environment (that is to say, networks and technologies related to telecommunications), the so-called “Data Layered Architecture” (DLA) is expected to become the deployment of choice for telecommunication operators. In short, the principle underlying DLA lies in decoupling specific application service logic (or “business logic”) for providing a service from the management of the data necessary to provide that service. This logical separation allows the application service logic and the data storage logic to be developed and maintained as modular components, which can be distributed over a number of separate platforms.
For example, a legacy “monolithic” network node, which includes a processing means programmed with appropriate logic to provide certain services using data stored in a data store that is integral to the node, can be converted into a DLA-compliant node by distributing its functionality among a number of application servers (widely referred to as front-ends, FEs) hosting the service logic, and a centralised data repository (which can comprise one or more back-end (BE) database systems) storing the data which the application servers use to provide their services.
An example of a monolithic node that can be converted into a front-end according to the Data Layered Architecture is a Home Location Register (HLR) of a mobile communications system, or a Home Subscriber Server (HSS) of an Internet Protocol Multimedia Subsystem (IMS). In these examples, any of the database systems commercially available today can be used as a back-end storage system making up the centralised data repository which serves the front-ends. In this kind of scenario, the front-ends become (standard) database clients of the back-end database system(s).
The DLA is just an example of a software architecture that may be employed in a system comprising a centralised database repository and one or more database clients each providing an application service by reading and/or modifying data which relates to that service and is stored in the database repository.
Although the software interfaces of the database client and the database repository's database management system (DBMS) are compatible with one another in a DLA-compliant system, this will generally not be the case for other types of systems. This incompatibility can present an obstacle if the front-ends demand flexible solutions allowing their integration with different back-ends. Similarly, back-ends may need to be integrated with applications other than those for which they were initially designed. Therefore, front-ends may rely on (source) data schemas and/or use (source) access protocols different from those (target) schemes and/or protocols offered by the back-ends. In these scenarios, a middleware layer function implementing the query reformulation process would be needed. However, this results in an extra penalty in performance, namely the latency in serving database queries that is caused by the middleware layer function reformulating the queries.
With the general aim of reducing the latency in serving database queries from database clients, efforts have so far focussed on reducing the latency which is introduced by the so-called query reformulation processes and, in general, on optimizing the process of serving a query by a database, by means of ad-hoc procedures.
For instance, one approach to speeding up the query reformulation process is to compile the data model mapping. With this approach, it is not necessary to parse the file containing the mappings every time a new query has to be reformulated. Another approach is to cache the transformation for each query issued by the front-end to avoid the time-consuming process of transforming that query into a format understandable by the BE and vice versa. For example, the transformation rules may be cached in a memory in order to reduce the time spent selecting the corresponding transformation rule for the input query.
Other known approaches seek to optimize the query plan to be executed in the database, in terms of a cost-based function. This is a common goal of query planners deployed within a DBMS, especially in relational databases. For example, when a query is submitted to the database, a query planner can evaluate some of the different, correct possible plans for executing the query and return what it considers to be the best alternative (normally in terms of cost-based considerations, such as the number of required accesses to a hard drive). Incidentally, the term “query plan” used herein takes its usual meaning in the art (where it is often also referred to as a “query execution plan”), as being an ordered set of steps (which may be expressed in any suitable database language) that can be performed by an interface to a database, such as a DBMS, so as to execute a query requested by a client of the database.
There are, however, several drawbacks with the aforementioned approaches for controlling the latency introduced by query reformulation process and, in general, for optimizing the query processing itself.
With the approach of compiling the data model mapping, the reduction in latency might be poor when it comes to reformulating complex queries and in cases where the model mapping is far from simple.
In the case of caching transformation rules, if the number of queries or their types are very high, the size of the cache required to store all possible transformations will introduce an extra latency owing to the need to manage a huge memory and to control the consistency of every transformation (cache controlling and data consistency).
Query planners and their corresponding optimizing functions are usually deployed within the DBMS, since they need a very detailed knowledge of the physical database design (normally in terms of the number of accesses to the hard disk) in order to optimize energy consumption and/or processing time. However, this kind of solution is difficult to implement in scenarios where multiple back-end databases are present (particularly, in a database federation) and they are basically intended for relational databases.
Accordingly, despite the efforts summarised above, there still remains a great need to find ways of reducing the latency in serving database queries from one or more database clients, particularly in applications such as those in the telecoms environment where the database clients often demand real-time data access.